Ogden  Air  Logistics  Center 


An  Uneasy 
Marriage? 

Merging 
Scrum  and  TSP 

Daniel  P.  Stormont 
Embedded  Systems  Engineer 
520  SMXS/MXDEA 
(801)  775-3191 
daniel.stormont@hill.af.mil 


Report  Documentation  Page 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 


1.  REPORT  DATE 

APR  2010 


2.  REPORT  TYPE 


3.  DATES  COVERED 

00-00-2010  to  00-00-2010 


4.  TITLE  AND  SUBTITLE 

An  Uneasy  Marriage?  Merging  Scrum  and  TSP 


6.  AUTHOR(S) 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Ogden  Air  Logistics  Center, 520  SMXS/MXDEA,Hill  AFB,UT, 84056 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 


5a.  CONTRACT  NUMBER 


5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

5d.  PROJECT  NUMBER 


5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 


12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 


13.  SUPPLEMENTARY  NOTES 

Presented  at  the  22nd  Systems  and  Software  Technology  Conference  (SSTC),  26-29  April  2010,  Salt  Lake 
City,  UT. 

14.  ABSTRACT 


15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF: 


a.  REPORT 

unclassified 


b.  ABSTRACT 

unclassified 


c.  THIS  PAGE 

unclassified 


17.  LIMITATION  OF 

18.  NUMBER 

ABSTRACT 

OF  PAGES 

Same  as 

40 

Report  (SAR) 

19a.  NAME  OF 
RESPONSIBLE  PERSON 


Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Overview 


Who  We  Are 


Agile  Methods 
Scrum 
■TSP 

Our  Process 
Successes 
Challenges 
Lessons  Learned 
The  Future? 


OGDEN  AIR  LOGISTICS  CENTER 


28  April  2010 


Systems  &  Software  Technology  Conference  2010 


2 


Who  We  Are 


OGDEN  AIR  LOGISTICS  CENTER 

Ogden  Air  Logistics  Center  is  the  major  organization  at  Hill  AFB  and  aims  to  be  America's  best  warfighter 
sustainment  organization.  It  is  one  of  three  such  centers  assigned  to  the  Air  Force  Materiel  Command, 
headquartered  at  Wright-Patterson  AFB,  Ohio.  It  is  the  largest  employer  in  Utah,  with  more  than  23,500  civilian, 
military,  and  contractors  supporting  an  estimated  7.5  million  production  hours. 

The  center  has  worldwide  engineering,  sustainment  and  logistics  management  and  maintenance  support 
responsibilities  for  some  of  the  Air  Force's  most  sophisticated  weapon  systems,  including  the  Minuteman 
intercontinental  ballistic  missiles.  The  center  is  the  Air  Force  Center  of  Industrial  and  Technical  Excellence 
(CITE)  for  low-observable,  'stealth,'  aircraft  structural  composite  materials  and  provides  support  for  the  B-2 

Spirit  multi-role  bomber. 

Program  management  for  two  of  the  Air  Force's  fighter  aircraft  is  performed  at  this  center.  Hundreds  of  F-16 
Fighting  Falcon  jet  aircraft  annually  receive  depot  maintenance,  modification  and  repair  on  the  base. 
Additionally,  the  number  of  A-10  Thunderbolt  Il's  that  receive  depot  level  inspections,  modifications  and 

maintenance  continues  to  grow. 

The  center  has  responsibilities  for  Air  Force-wide  item  management,  depot  level  overhaul  and  repair  for  all 
types  of  landing  gear,  wheels,  brakes  and  tires  and  is  the  logistics  manager  for  all  conventional  air  munitions, 
solid  propellants  and  explosive  devices  used  throughout  the  Air  Force.  The  center  is  the  Air  Force  technical 
repair  center  for  composites.  In  addition,  the  center  provides  a  full  range  of  sustainment  and  logistics  support 
for  space  and  command,  control,  communication  and  intelligence  systems. 

The  center  is  also  responsible  for  mature  and  proven  aircraft,  as  well  as  providing  photonics  imaging  and 
reconnaissance  equipment;  aircraft  and  missile  crew  training  devices;  avionic,  hydraulic,  pneudraulic  and 
radar  components;  instruments;  gas  turbine  engines;  power  equipment  systems;  special  purpose  vehicles; 

shelters;  and  software  engineering,  development  and  support. 


28  April  2010 


Systems  &  Software  Technology  Conference  2010 


3 


Who  We  Are 


■ 


OGDEN  AIR  LOGISTICS  CENTER 


The  309th  Maintenance  Wing  is  a  world-renowned  source  of 
maintenance,  repair,  overhaul  and  modification  for  the  F-22  Raptor,  F- 
16  Fighting  Falcon,  A-10  Thunderbolt  and  C-130  Hercules  aircraft,  as 
well  as  the  ICBM  Minuteman  missile  system.  The  wing  possesses  a 
skilled  workforce  of  approximately  8,000  military  and  civilian 
employees,  and  its  294  facilities  cover  5.2  million  square  feet  of 
production  and  support  areas  at  nine  operating  locations,  including 
repair  organizations  in  the  Pacific  and  in  Tucson,  Arizona. 

Within  the  309  MXW  are  seven  major  business  groups  involved  with 
aircraft,  commodities,  electronics,  software  and  missile  maintenance; 

maintenance  support;  and  aircraft  and  aerospace  assets 
maintenance,  storage  and  regeneration.  Each  group  has  formidable 
combinations  of  skilled  technicians  and  strategic  commercial 
relatiionships  to  successfully  respond  to  customer  needs.  The 
growing  industrial  capabilities  have  been  sharpened  by  modernizing 
facilities,  acquiring  new  equipment  and  refining  competitive 
processes,  and  genuine  concern  for  customer  needs 
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Command  and  Control  System  - 
Consolidated  (CCS-C) 

Mission 

CCS-C  provides  consolidated  MILSATCOM  tracking, 
telemetry  and  command  (TT&C)  capability  for  14th 
Air  Force,  50th  Space  Wing  launch  and  early  orbit,  on 
orbit  and  anomaly  resolution  space  operations. 


Features 


CCS-C  is  currently  configured  to  support  MILSATCOM  satellites  across  four  satellite  constellations:  Defense 
Satellite  Communications  System  (DSCS);  Milstar;  Wideband  Global  SATCOM  (WGS);  and  Advanced  Extremely  High 
Frequency  (AEHF)  System.  CCS-C  consists  of  high  specification,  commercially  available  computer  servers  and 
workstations  running  commercially  available  TT&C  software  packages  on  a  local  area  network-based  client/server 
architecture.  CCS-C  enables  customizable  Task  Automated  Operations  which  dramatically  reduce  operator  workload 
enabling  Air  Force  Space  Command  (AFSPC)  to  decrease  operator  crew  size  while  ensuring  sufficient  TACON  of 
America's  MILSATCOM  satellites.  CCS-C  is  operational  at:  AETC  /  533rd  Space  Training  Squadron  at  Vandenberg 
AFB;  14th  Air  Force  /  50th  Space  Wing  /  3rd  and  4th  Space  Operations  Squadrons  at  Schriever  AFB,  CO.  A  CCS-C 
Backup  Satellite  Operations  Center  at  Vandenberg  AFB  (BSOC-V)  was  activated  July  2008. 
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ccs-c 

OGDEN  AIR  LOGISTICS  CENTER 

■CCS-C  Software  Sustainment  Team 

■  We  are  a  small  team  of  engineers  and  computer 
scientists  working  to  establish  a  software 
sustainment  capability  in  support  of  our  customer 

■  Our  primary  roles  at  present  are 

•  Develop  expertise  in  the  space  domain 

•Gain  system  expertise  with  CCS-C 

•Help  to  fill  in  the  gaps  in  the  existing  system 
documentation 

•  Improve  the  quality  of  the  system  code 

•  Establish  a  process  to  integrate  the  contractor  and 
government  efforts  in  the  development  and  sustainment 
of  the  system 

•Stand  up  a  software  sustainment  capability  at  OO-ALC 
within  the  next  five  years 
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■ 


Agile  Methods 


OGDEN  AIR  LOGISTICS  CENTER 


■  The  Agile  Manifesto 


We  are  uncovering  better  ways  of  developing  software  by  doing  it  and 
helping  others  do  it.  Through  this  work  we  have  come  to  value: 

Individuals  and  interactions  over  processes  and  tools 
Working  software  over  comprehensive  documentation 
Customer  collaboration  over  contract  negotiation 
Responding  to  change  over  following  a  plan 

That  is,  while  there  is  value  in  the  items  on  the  right,  we  value 

the  items  on  the  left  more. 


(From  the  Agile  Manifesto  website) 
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Agile  Methods 


OGDEN  AIR  LOGISTICS  CENTER 


■Some  commonly  employed  agile  methods, 
according  to  Wikipedia 

■  Agile  Modeling 

■  Agile  Unified  Process  (AUP) 

■  Dynamic  Systems  Development  Method 
(DSDM) 

■  Essential  Unified  Process  (EssUP) 

■  Extreme  Programming  (XP) 

■  Feature  Driven  Development  (FDD) 

■  Open  Unified  Process  (OpenUP) 

■  Scrum 
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Key  concepts 
■Sprint 
■Backlog 

•Project 

•Sprint 

■Daily  standup 

■Deliverable  increment  of  functionality 
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Scrum 


OGDEN  AIR  LOGISTICS  CENTER 


Sprint  Backlog 


Daily  Scrum 
Meeting 


Backlog  tasks 
expanded 
by  team 


v  Product  Backlog 

As  prioritized  by  Product  Owner 


Demonstrable 
new  functionality 


Source:  Adapted  from  Agile  -Scrtware 
Cb  velop  ment  with  Scnm  by  Ken 
Schwaber  and  Mke  Beedle. 


IH 
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TSP 


OGDEN  AIR  LOGISTICS  CENTER 


The  Team  Software  Process  (TSP),  along  with  the  Personal  Software 
Process,  helps  the  high-performance  engineer  to 

*  ensure  quality  software  products 

*  create  secure  software  products 

*  improve  process  management  in  an  organization 

Engineering  groups  use  the  TSP  to  apply  integrated  team  concepts  to 
the  development  of  software-intensive  systems.  A  launch  process 
walks  teams  and  their  managers  through 

*  establishing  goals 

*  defining  team  roles 

*  assessing  risks 

*  producing  a  team  plan 


After  the  launch,  the  TSP  provides  a  defined  process  framework  for 
managing,  tracking  and  reporting  the  team's  progress. 


Using  TSP,  an  organization  can  build  self-directed  teams  that  plan 
and  track  their  work,  establish  goals,  and  own  their  processes  and 
plans.  These  can  be  pure  software  teams  or  integrated  product  teams 
of  3  to  20  engineers.  (From  the  SEI  TSP  website) 


TSP  will  help  your  organization  establish  a  mature  and  disciplined 
engineering  practice  that  produces  secure,  reliable  software. 
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PSP 


The  Personal  Software  Process  (PSP)  shows  engineers  how  to 
•manage  the  quality  of  their  projects 
•make  commitments  they  can  meet 
•improve  estimating  and  planning 
•reduce  defects  in  their  products 


OGDEN  AIR  LOGISTICS  CENTER 


Because  personnel  costs  constitute  70  percent  of  the  cost  of 
software  development,  the  skills  and  work  habits  of  engineers 
largely  determine  the  results  of  the  software  development 
process.  Based  on  practices  found  in  the  Capability  Maturity 
Model  (CMM),  the  PSP  can  be  used  by  engineers  as  a  guide  to 
a  disciplined  and  structured  approach  to  developing  software. 
The  PSP  is  a  prerequisite  for  an  organization  planning  to 
introduce  the  TSP. 

The  PSP  can  be  applied  to  many  parts  of  the  software 
development  process,  including 
•small-program  development 
•requirement  definition 
•document  writing 
•systems  tests 
•systems  maintenance 
•enhancement  of  large  software  systems 


(From  the  SEI  TSP  website) 
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Our  Process 


Sprint 

Backlog 
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Our  Process 


OGDEN  AIR  LOGISTICS  CENTER 


■  Our  version  of  the  Scrum  lifecycle 

■  The  length  of  the  sprint  is  defined  by  the  time 
period  between  Program  Status  Reviews  (PSRs) 

•Typically  2  months 

■  The  project  backlog  is  all  of  the  items  in  our  WBS 

■  The  team  uses  historical  TSP  data  and 
engineering  judgment  to  break  the  WBS  items  out 
into  the  tasks  needed  to  accomplish  them  and 
then  to  fit  the  tasks  into  the  available  task  hours  in 
the  sprint 

■  We  hold  daily  standups  -  except  for  one  day  a 
week  when  we  hold  a  TSP  weekly  meeting 
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Our  Process 


OGDEN  AIR  LOGISTICS  CENTER 


■  TSP  tool 

■  The  tool  we  use  to  automate  the  rather  large  amount  of 
data  collection  required  by  TSP  is  the  Process 
Dashboard 

■  This  is  an  open  source  Java-based  application 
developed  by  Tuma  Solutions,  LLC  and  is  available  at 
www.processdash.com 


< 


Time  entry  via  "Play  /  Pause”  buttons 


\  Defect  entry 
Percent  Spent  Indicator 


jfg|  Project  My  Project  Release  1  Component  A  Code 


Process  scripts/summary  forms  button 


Task  navigation  style  selector 


Project  hierarchy  menus  -  select  active  task 


Phase  complete”  checkbox 


Note  Indicator 


"Configuration"  menu  -  special  features 
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W  n  P 

Our  Process 
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Our  Process 


OGDEN  AIR  LOGISTICS  CENTER 


■  Process  Dashboard  Team  Members 
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Our  Process 


OGDEN  AIR  LOGISTICS  CENTER 
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Our  Process 
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■  Process  Dashboard  Time  Estimation 
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■Process  Dashboard  PROBE 


Estimation 

method 

choice 

Independent 
variable  (X) 

Dependent 
variable  (Y) 


Prediction 

interval 

entry 


Estimate 

entry 


Averaging 
calculation  metrics 


Linear  regression 
calculation  metrics 


28  April  2010 


Systems  &  Software  Technology  Conference  2010 


18 


■■ 


OGDEN  AIR 


Our 


Process 


■  Process  Dashboard  Defect  Log 


Defect  button 


LOGISTICS  CENTER 


Defect  type  pulldown 


Defect  injected  phase  pulldown 


Defect  removed  phase  pulldown 


Fix  defect  ID  entry 


New  fix  defect  button 


Fix  time  display 


Defect  timer  start/stop  button 


Defect  description  pane 


v  C3  Protect 
•"  L3  My  Protect 

►  □  web  Protect 

►  |^J  SOA  Protect 
y  C3  Legacy 

?  L3  Product  t 

- 

«►  (3  Product  2 
l3  Product  3 
•-  Q  Non  Protect 


StomlMit:  Inherit 


l.lnlxl 


Proteci  ID  Type 

Inierted 

Removed 

Time 

Fix  Description 

/Proiect/Legacy/Product  1/SC R  42  ’  Function 

Design 

Design  Review 

1 

{Calculation  logic  was  no 

/Pruteit/Lpgric/Producl  1/SCR  4:  ?  Interface 

Design 

Design  Review 

6 

]Param  list  mismatch 

/ProlecULegacy/Produit  l/SCR  42  3  Checking 

Design 

Design  Review 

3 

Boundary  conditions  In  c 

/Pi0|6l L'Leuacv/Prtiiiuct  l/SCR  42  4  Checking 

Design 

Design  Review 

2 

/ProiecULeoacy/Proautt  i/SCR  4  2  5  Syntax 

Code 

Code  Review 

0.1 

isemicolon 

/ProiocWLe-aacy/Proauci  i/SCR  42  6  Syntax 

Code 

Code  Review 

0.2 

imismalched  parens 

.'Proiect/Legacy/F'roduct  1/SCR  42 1 7  Syntax 

Code 

Code  Review 

0.4 

isemicolon 

/Proiect'Leoacy/ProdUct  1/SC  R  42  9  Syntax 

Code 

Code  Review 

04 

,1ypo  in  constant  fleelerafc 

/Proterl/LegacyVProductl/SCR  42  9  Syntax 

Code 

Code  Review 

0  1 

Itypo 

/Pro|ect/Legacy/Pf®Jin.»  t/SCR  42  10  Function 

Design 

Code  Review 

21 

!M>ssed  business  logic  u 

■'P»u|ect/LegacyifP«niuet  1/SCR  42  tl  Interface 

Code 

Code  Review 

4 

jparam  type  mismatch 

/Proiect/Legacv/Ffoduct  1/SCR  42  »2  Checking 

Code 

Code  Review 

6.8 

INot  handling  null  input  v: 

- 

•  / 

> 

Hierarchical  project  view 


Defect  entries 


28  April  2010 


Systems  &  Software  Technology  Conference  2010 


15 


■ 


Our  Process 
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■  Process  Dashboard  Reports 


■ 
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Our  Process 
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■  Sprint  planning 

■  Using  Process  Dashboard,  each  team  member 
enters  their  planned  task  hours  for  the  sprint 

■  The  highest  priority  tasks  are  estimated  in  detail 
by  the  team,  using  historical  data 

■  The  tasks  are  copied  into  a  new  sprint  project  one 
by  one  until  the  available  task  hours  are  used 

■  Team  members  “accept”  tasks  in  the  project  to 
create  a  balanced  plan  and  get  a  planned  value 

■  Team  members  synchronize  their  dashboards  to 
get  the  project  tasks  in  their  personal  dashboards 

■  Team  members  prioritize  their  tasks  by  arranging 
them  in  the  order  they  plan  to  work  them 
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Our  Process 
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■Our  process  and  CMMI 

■I  believe  that  our  TSP/Scrum 
integration  does  support  many  of  the 
process  areas  of  the  CMMI 

■This  is  an  area  that  needs  further 
research 
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■  Scrum  and  TSP  integrate  very  well 

■  One  weakness  of  Scrum  (in  my  opinion)  is  the 
estimation  of  backlog  tasks 

•Frequently  done  using  “requirements  poker” 

■  TSP  provides  a  robust  set  of  metrics  and  effort 
planning  tools 

■  Both  Scrum  and  TSP  have  short  time  cycles 
before  replanning  is  required  (on  the  order  of 
months) 

■  TSP  provides  daily  status  on  individual  and  team 
performance  and  can  highlight  schedule  variances 
in  “real  time” 

•This  feeds  into  the  Scrum  daily  standup 
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■Responsiveness  to  customer 

■The  detailed,  yet  short-ranged,  planning  of 
both  Scrum  and  TSP  -  combined  with  the 
TSP  metrics  -  supports  being  responsive  to 
the  customer 

•Can  give  accurate  estimates  of  priority  changes 
or  “drive  by  taskings” 

■The  customer  can  adjust  priorities  every 
two  months  as  their  needs  dictate 
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■Good  metrics 

■With  TSP,  the  team  knows 

•How  long  a  task  that  is  familiar  will  take 

•How  long  an  unfamiliar  task  similar  to  a  familiar 
task  should  take 

•If  an  estimate  was  not  correct  on  a  daily  basis 

•How  many  task  hours  each  team  member  can  be 
expected  to  produce 

•How  many  defects  have  been  injected  by  phase 

•How  effective  the  quality  steps  are  and  how 
much  effort  they  require  (the  cost  of  quality) 

•EV  by  team  and  team  member 
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■Better  programmatic  understanding 

■Longer  range  estimates  have  more  fidelity 
because  they  can  be  gauged  against 
previous  estimates 

■The  effectiveness  of  process 
improvements  can  be  judged  empirically 

■  Positive  and  negative  trends  become 
readily  apparent  and  adjustments  can  be 
made  to  continue  the  positive  trends  and 
correct  the  negative 
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Challenges 

'  OGDEN  AIR  LOGISTICS  CENTER 

■It's  different! 

■TSP  and  Scrum  were  new  to  the 
customer 

■TSP  is  new  to  many  of  the  teams 
at  OO-ALC 

■Scrum  is  new  to  OO-ALC 
■People  tend  to  resist  change 
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Challenges 


OGDEN  AIR  LOGISTICS  CENTER 


■Where's  the  Gantt  chart? 

■Customers  and  managers  have  been 
trained  by  decades  of  experience  to 
think  that  they  need  a  Gantt  chart  to 
manage  a  project 

■Concepts  like  backlogs  and  short 
duration  iterations  make  them 
uncomfortable 
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Challenges 
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■  Is  this  really  software  engineering? 

■  To  engineers  used  to  having  a  project  plan  that 
runs  for  the  entire  length  of  a  project  feel  that  a 
two  month  plan  is  too  ad  hoc 

•  Not  that  it  isn't  possible  to  generate  a  long  range  plan 
from  the  backlog,  it  just  has  about  as  much  fidelity  as 
most  long  range  plans 

■  To  engineers  used  to  being  assigned  tasks  by 
managers  used  to  assigning  tasks,  the  notion  of 
“accepting  tasks”  and  having  daily  meetings 
seems  too  “soft  and  fuzzy” 

•  “What,  are  we  going  to  have  a  group  hug  now?” 
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Lessons  Learned 
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■  Educate  the  stakeholders 

■  Customers,  management,  process  leaders,  and 
team  members  need  to  be  educated  early  and 
often  about 

•What  the  new  methods  are 

•  How  they  are  different  from  what  they  are  used  to 

•  How  they  are  the  same  as  what  they  are  used  to 

•What  the  advantages  of  the  new  methods  are 

•What  the  disadvantages  of  the  new  methods  are 

■  The  team  members  need  to  have  training  in  the 
methodologies  (PSP,  TSP,  and  Scrum)  before  they 
try  to  use  them 
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Lessons  Learned 
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■Avoid  too  much  “agile  speak” 

■Agile  has  it's  own  vocabulary 

■  Many  of  the  agile  terms  are  really  just  new 
ways  of  referring  to  old  or  common  sense 
ideas 

■  If  you  can  avoid  using  these  unfamiliar  terms 
or  you  can  use  them  in  ways  that  are  more 
familiar  to  your  audience  -  do  so 

■  There's  nothing  “leading  edge”  about  being 
misunderstood 
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Lessons  Learned 
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■  Ensure  you  have  buy-in 

■  Buy-in  from  the  customer 

•We  did  this  through  briefings  to  the  customer  and 
through  a  one-day  scrum  workshop 

■  Buy-in  from  management 

•Done  through  ongoing  education  and  by  trying  to 
demonstrate  the  value  of  Scrum  and  TSP 

■  Buy-in  from  the  team 

•Most  essential 

•Engineers  have  a  tendency  to  be  skeptical  and 
resistant  to  change 

•Need  to  see  the  benefits  for  themselves  before 
they'll  accept  something  new 
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Lessons  Learned 
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As  in  any  team  endeavor, 
effective  communication  is 

essential! 
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The  Future? 
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■The  future  for  Sprint  and  TSP 
integration  in  CCS-C  sustainment  at 
OO-ALC  is 


Uncertain! 
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Questions? 
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